Less Is More: The Minimum Context for a Better Decision

昨天，我們想做的 Decision Engine 已經呼之欲出：

弱掃報告提供漏洞資訊；企業補上足以改變判斷的脈絡；Decision Engine 產生可解釋的處置優先順序。

第一版規格：

Scanner Result
      +
Minimum Context
      +
Decision Rules
      ↓
Decision Engine
      ↓
Priority + Explanation

先不做自動修補、Ticket Workflow、完整 CMDB 整合，也不急著做 Dashboard。

昨天畫出的「我們」，今天不能全部搬進來

Day 4 把工具看不見的企業場景畫了出來；環境、網路位置、服務、業務重要性、Owner、相依性、防護措施……都有可能影響風險。但：

全部都重要，等於沒有 MVP。

所以反過來要思考：

少了什麼，Decision Engine 的判斷就可能失真？

我把它叫做 Minimum Context。

它不是通用答案。每家公司都有自己的架構、控制措施與營運經驗。

方法可以共用，Decision Rules 必須長在自己的企業裡。

Minimum Context v0.1

弱掃報告中已有了弱點的資訊 Asset / CVE / CVSS

我在第一版保留屬於我的企業情境中，真正參與判斷的企業脈絡：

Reachability
Control Effectiveness
Business Criticality

另外保留：

Service
Environment

用來定位與解釋，但暫時不進公式。

另外這幾組企業情境，先選擇用經驗收斂的值：

Owner 先不進 Decision Engine，它回答的是「何人處理」；這一版先回答：哪個漏洞更優先處理。

Decision Engine 算的是 Priority

產生可解釋的處置優先順序

還記得 Day 3 的三把尺嗎？

漏洞有多嚴重 (CVSS)
實際曝險有多高 (Effective Exposure)
出事影響有多大 (Business Impact)

現在我們透過正規化和加權模型組合，將這３個不同來源看似獨立的指標，組裝成 Decision Engine 可以計算的東西。

曝險(Effective Exposure)不能只看是不是對外

Internet-facing 代表有攻擊路徑，但現有防護會改變實際曝險。

Effective Exposure = Reachability × Control Effectiveness

這裡要注意，UNKNOWN 不降分，是因為不知道，就不能假裝已有防護。

Business Impact：

CRITICAL  = 1.0
IMPORTANT = 0.7
NORMAL    = 0.4

評分結果分級：

9.0–10.0  Critical
7.0–8.9   High
4.0–6.9   Medium
0–3.9     Low

這就是 Decision Engine v0.1 的起始假設：先讓三把尺變成一套可計算、可驗證，也可以被實際案例推翻。

Case A / B，再驗一次

Case A

經過Decision Engine的計算，重新解釋處理等級為Medium

CVSS Severity       = 9.8 / Critical
Contextual Priority = 6.25 / Medium

漏洞沒有變得不嚴重。
只是放回企業場景後，它現在不必排在最前面。

Case B

經過Decision Engine的計算，重新解釋處理等級為High

Case A：CVSS 9.8 → Priority Medium
Case B：CVSS 8.8 → Priority High

也顯示出如果 Case B 沒有有效控制，則有機偎使 Priority Score = 9.40 / Critical

補償性控制因此真正進入 Decision Engine，而不只是報告裡的一句描述。

少即是多

這一版不完整，但已經足以回答：

加入最少但必要的企業脈絡後，Decision Engine 能不能做出比單看 CVSS 更有用，而且說得出理由的處置順序？